What is Class Structure in Pega?

What is a Class in PEGA?

Class contains the rule by which objects behave. Define rules such as properties, activities, flows, HTML forms, etc. available to other subordinate classes. Classes are organized into a hierarchy in which lower classes inherit from upper classes. A class is an instance of a rule-obj-class rule.

Types Of Classes

Abstract Class

• An abstract class is a rule (an instance of the Rule-Obj-Class class) created to support the definition of rules in PRPC. Such rules can be inherited by subclasses of the abstract class.
• Any abstract class name in PRPC usually ends with the symbol ‘-‘, For example, Data-.Work- are abstract classes in PRPC. MyClass-
• Whenever we create a first abstract class it’s parent class should be @baseclass. For second abstract class, the parent class will be the first abstract class and so on.
• Abstract classes cannot be instantiated.

Concrete Class

• A Class that is not abstract is a concrete class. Concrete classes DO NOT end with a ‘-‘. MyClass
• Whenever we create a first concrete class its parent class should be ‘Work-‘. For second concrete class the parent class will be it’s class group.

Inheritance

There are two types of inheritance:-

• Pattern inheritance — It is an optional feature we can set up for a class in the Rule-Obj-Class rule, affects the first steps in the rule resolution algorithm. This approach is sometimes called “dual” inheritance. During rule resolution, pattern inheritance causes a class to inherit rules first from classes that match a prefix of the class name.
• Directed inheritance — Allows us to name a parent class, choosing a name that’s not related to the name of this class

What is Class Structure in PEGA?

Class Structure design is an integral part of every Pega application. Designing a scalable, extensible enterprise class structures from the beginning of your project will help avoid costly re-factoring. The enterprise class structure enables PRPC applications to co-exist with each other and with customer or Pega built frameworks. The enterprise class structure is also the foundation for enterprise reuse. Asset reuse is integral to the long-term success of BPM within the organization, and ultimately, the reusability requirements drive the selection of your class hierarchy design.

Hierarchy Of a Class Structure:

Layer Definition:

PRPC Base Product Layer:

• The PRPC Base Product Layer consists of the Pega-4 RuleSets and its classes & rules. Loaded as a part of the PRPC platform install, this layer contains all rules necessary for workflow processing and other areas of Process Commander.
• While the Pega-4 RuleSets are locked, rules that apply to many of the Pega classes (Work-, Embed-, Data-, @baseclass, etc.) can be defined in application RuleSets to support enterprise-wide reuse.

Enterprise Reuse and Divisional Reuse Organizational Layers:

• The Enterprise Reuse and Divisional Reuse Organizational Layers is where extensions to the work and data classes exist.
• This may include enterprise wide or division wide business logic (standard properties, flows, decision tables, models, SLA rules, etc.), data classes (such as generated class structures for connector request/response messages) as well as other extensions exist.
• The classes within the Divisional Reuse layer inherit from their counterparts in the Enterprise Reuse layer; the classes of the Enterprise Reuse layer inherit directly from the Work- and Data- classes.

These core tutorials will help you to learn the fundamentals of Pega. 
For an in-depth understanding and practical experience, explore Pega Training.

Framework Layer:

• The Framework Layer stores base rules/processes/components for a given application. A customer built framework (CBF) serves as the basis for N number of deployments throughout the enterprise.
• A CBF must be able to stand on its own. Therefore, this layer contains all rules necessary to implement its functionality. While there will be a class group and its mapping to a database table for testing purposes, the actual mapping of the application to production database table occurs on the Implementation layer.
• Organization specific logic, processes and rules must be placed on the Implementation layer as well, only default edits, values, and application structures have their home in the CBF layer.
• This layer can also be used to extend any features present in a Pega based framework for a particular organization.
• In this case, there are one or more specialization layers on the Implementation level and the CBF and the Pega solution framework on the Framework level. The CBF has the Pega framework as its directed parent.

Implementation Layer:

• The Implementation layer contains the rules necessary to implement a Pega built framework or Customer Built Framework (CBF). This layer contains all specialization rules as well as the application class group(s) of the framework for the organization and division that it belongs to. The layer also contains flow shells and/or service activities used to start their generalized counterparts in the Framework layer.
• The EAA now creates an Enterprise Class Structure consisting of a CBF on the Framework layer and organizational implementation classes on the Implementation layer.

 Class Structure and Reusability:

• A robust class structure is the foundation of reuse throughout your application. The PRPC recommended class structure design pattern offers flexibility in your design and provides for more level of reuse.
• The class structure provides the first and most important layer of reuse in PRPC due to its precedents in the rule resolution algorithm.
• The class structure provides you with a hierarchy in which rules can be placed. The higher a rule is in the hierarchy, the more potential reuse there is.
• The key to a good class structure is that there are enough layers and classes to hold the most fundamental levels of reuse but not too many that it becomes cumbersome to navigate and unclear as to the intent.

Class Structure and Security:

• Class Structures also help in applying security controls across the organization.
• It can be achieved by defining access role objects which map access roles to certain classes. Users having those roles can then Open/modify/delete instances of that particular class.
• Then assign these roles to the users who you want to be able to access the functionalities defined via those classes.

For in-depth understanding of Pega click on

• Pega Process Managment
• Class structure in Pega 
• PegaRULES Database
• Operator rules